ROS for your robotic MVP. To use or not to use?

Gabriele Ermacora
4 min readJan 25, 2022
The Husky A200 a popular robotic platform tested for logistic tasks in construction. Image Credit: © LIVE-STYLE Eppan

Imagine this scenario: You’ve successfully validated the market with visits and interviews. Now the clients are pushing you to see the real robotic MVP (Minimum Value Product) on their site. Awesome! But you have to move fa$t. How? You might want to consider using an ROS (but with limits).

ROS (Robotic Operating System) , is a standard defacto open source operating system for robotics, originally created for education and research purposes. It is a great software tool that can help you churn out your MVP faster. But here is what I think you need to know in advance:

  1. Limited embedded support — This only matters for industrial applications that need ROS to run on an embedded system and ROS does have embedded support for some hardware. It just depends on whether that hardware is appropriate for the application.
  2. Can’t be used in real-time systems — “real-time” means something very specific, which is fixed timestep processing that can’t be blocked other processes. Some systems may or may not need real-time and that real-time doesn’t need to be handled at the OS/ROS level. For example, the real-time process can happen on an embedded system and the communication to that system does not need to be real-time. So for industrial applications that don’t need real-time processes at the OS/ROS level, ROS is completely fine.
  3. Not secure — Yes, ROS is not secure but there are workarounds for making it secure using VPN to encrypt the communications.
  4. No multi-robot support — The ROS master architecture does have some limitations for supporting multi-robot applications but again there are workarounds.
Source the RobotReport

Indeed, and again quoting Melonee “ROS does have some limitations but those limitations haven’t prevented some companies, like Fetch Robotics, from building successful companies and products with ROS”. Here are some more examples in “Top 10 ROS-based robotics companies in 2019” — though the majority are in R&D or education. Is ROS 2 a more robust framework for commercial applications? The open source community believe so. Here are some major improvements on the architecture (“ROS1 vs ROS2, Practical Overview For ROS Developers”): let’s see in the next couple of years.

  • Don’t waste time reinventing the wheel, especially for mobile robotics. Ricardo Tellez explains in his post (On not using ROS for your robotics startup) in details why ROS could be an advantage in comparison to starting from scratch. Just for the sake of objectiveness, keep in mind that he is also the founder of an educational company teaching ROS (The Constructsim). But I 100% agree on his comments, especially on the fact that you can consider building your robotic MVP in ROS and then develop your own robot with a different software architecture for mass production.
  • The above is valid for mobile robotics MVP. Although I am aware of the impressive recent developments of ROS Industrial, to me, industrial applications in ROS stay in the field of R&D or education and are not ready for a business MVP.
  • Are we sure I can sell an open source robotic application based on ROS? Short answer: normally yes. Long answer: ROS embraces the open source philosophy. ROS open source means you can access the source code of the software. However, you should respect the license agreement according to the open source (From “Can you commercially sell something that uses ROS, the open source Robot Operating System?” ):

BSD license: You must mention in the derived products that it’s this license for the component, that is, have a copy of the license notice. Also you say that you are not responsible for any bad things that can happen due to misuse of software.

GNU GPL: You must redistribute the license on unmodified code. “You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.” You must redistribute the license and also say when (and also by who) the modifications have occurred on modified code. The entire derivative product also falls under this license. You cannot make the program closed-sourced, that is, if you give the compiled program you need to offer a way for its source code to be accessible, paid or free. (there are more things that I have not read)

GNU LGPL: You are only interested in selling; since GPL allows this then LGPL, which only adds additional permissions, also allows selling.

Creative Commons: This one does not allow selling. (and is the only one)

There is also a limit to how much the open source community can help you (forget about customer support). There is no binding contract that will guarantee you a flawless software.

As a conclusion, although I believe ROS 1 (or 2) are probably not the best way to mass produce a mobile robot, it is a great way to produce a quick-and-dirty prototype to test your market. In my experience with robotics and innovation, getting your product out even without it being 100% in order to get feedback from your customer will ultimately save you both time and money.

Thank you!

  • If you enjoyed this post and want to connect with me, subscribe to my mailing list here or drop me a message at ermacora [dot] gabriele [at] gmail [dot] com
  • Or connect on Linkedin!

--

--

Gabriele Ermacora

AI consultant bridging Europe & China Passionate about people, robots & business. Helping organizations achieve their ESG goals. www.gabrieleermacora.com